A Review of Log4Shell Detection Methods
Ever since the public exploit of the Log4Shell remote code execution (RCE) vulnerability became known on December 10, 2021, security teams have been scrambling to understand the risk to their environments. Part of that scramble has been to ascertain which tools are best positioned to help detect the vulnerability. Which approaches are most effective and where do they fall short? In this blog post, we'll describe some of the ways that Log4Shell vulnerabilities can be detected and discuss the pros and cons of each.
Software Composition Analysis (SCA)
SCA tools are focused on risks associated with third-party libraries. As such, they are well-suited to identify the presence of vulnerable log4j-core components in Java applications and other Java codebases. It's important that the SCA tool pinpoints and reports the exact version that is being used as there has been a flurry of releases of log4j-core in the past two weeks. As of this writing, 2.17 is considered the only fully safe version. Versions 2.15 and 2.16 were initially released to address Log4Shell, but it has since been found these fixes were insufficient. Check Veracode's detailed Log4Shell blog post for the most up-to-date information.
Any tool that reports the presence of Log4Shell just because "log4j" appears in the file name will result in false positives and time wasted. For example, the libraries "log4j-api" and "log4j-web" are not vulnerable to Log4Shell. The same is true for log4j versions 1.x. However, the 1.x versions need to be updated too. They contain other serious RCE vulnerabilities and reached end of life as well, so there are no new releases.
Make sure your SCA tool analyzes the full codebase, including transitive dependencies. It's not enough to inspect only the POM file for a Maven-based code repository. The POM references only direct dependencies that the developers included. The way software is built today, all required components that aren't referenced in the POM (like transitive dependencies) are pulled in automatically when a build is run to construct the full application that's suitable for deployment.
Veracode SCA offers a robust solution to detect Log4Shell across your environment. Scanning can be done by uploading a pre-built application or by scanning while building the project from the command line, a script, or within a CI pipeline. Java-based package managers Maven, Gradle, and Ant are supported as well as plain JAR and/or WAR files.
As a result of this latest vulnerability disclosure, Veracode customers are taking more advantage of advanced SCA capabilities. With Veracode SCA, you can leverage the Vulnerable Methods feature to help see not only if you have a finding but if you are invoking via your custom code. Once you’ve identified a vulnerable application, automated pull requests can be generated to simplify remediation.
The Veracode Vulnerability Database keeps a record of vulnerabilities in open source components and is automatically updated to reflect the changing state of the entire open source ecosystem, including log4j-core. And with Veracode SCA, results are updated automatically when new vulnerabilities are discovered in open source components. Running a new scan is not necessary. Similarly, Veracode users can choose to watch their projects to receive an email notification if the security posture of their projects changes.
Veracode SAST customers who take advantage of our courtesy SCA license offer don't have to run any further scans on their applications because the platform keeps an inventory of all open source dependencies (direct and transitive) and versions used. All they needed to do is log into their account and filter by component name or CVE ID to find out if they are using vulnerable versions of the Log4J library.
Dynamic Application Security Testing (DAST)
DAST is a quick & easy way to scan public-facing web applications, especially against the unauthenticated surface area of the applications. While a DAST scan can tell you if it found a vulnerability, it’s unable to indicate where in the codebase to fix the issue or help identify the development team that is responsible for the application.
For full coverage and best assurance that your web apps are not vulnerable to Log4Shell, it would be important to run not only unauthenticated scans but also an authenticated scan for each user role supported by the web application. Setting up authenticated scans against your web apps would require a much larger level of effort.
Also, keep in mind that authenticated DAST scans against production environments can be risky as the scanner would have access to the same functionality as the user. It's possible that production data could be altered or deleted by the scanner if an authenticated scan is run against a production web app. Running an authenticated scan in production with a high-privilege user or administrator is especially risky and not recommended.
Due to the nature of Log4Shell, a DAST tool that supports an out-of-band detection mechanism, such as a DNS sensor, may work best for finding vulnerable web apps. Examples are Burp Collaborator and Qualys Periscope. The Veracode Dynamic Analysis team is actively working on releasing a detection for Log4Shell.
If your DAST tool does find a Log4Shell vulnerability on your scanned web app, consider using the Logout4Shell tool as a quick fix to at least prevent exploitation by adversaries. This tool leverages the Log4Shell vulnerability itself to execute a payload on the server that disables the log4j setting that allows for exploitation. (We recommend using the tool's transient mode only as a temporary measure until the library can be updated to a safe version.)
Static Application Security Testing (SAST)
The main purpose of SAST is to identify security flaws in first-party code, which developers write to build the required functionality of their application. Some have questioned why SAST tools did not report the Log4Shell vulnerability years ago. First, the log4j code would need to be scanned, but open source libraries are not commonly scanned with SAST as the focus is first-party code.
Veracode SAST customers have a unique advantage. Software composition analysis is conducted alongside the static analysis of the first-party code. Nothing extra is required in terms of setup or packaging to have the SCA results. This allows for Veracode SAST and SCA customers to quickly have visibility into which of their applications include a vulnerable log4j library.
Additionally, Veracode customers with low risk tolerance for flaws in open source projects have the option of reporting findings to library maintainers that come from these libraries during a SAST scan of their own apps. That being said, few customers take this path. The SCA solution is purpose-built to identify known security issues in such libraries.
NOTE: If you are currently a Veracode SAST customer but not licensed for SCA, please contact your Veracode representative for information on a courtesy SCA license.
Network/Infrastructure Scanning
Finding vulnerable log4j components with infrastructure scanning is potentially feasible if your organization already has a solution in place. Otherwise, it would require significant effort to get the scanning up and running across your cloud and on-premises networks. Infrastructure scanning to identify Log4Shell would also require that the scanner has the ability to log into the OS on the machines you wish to scan.
Additionally, while they can be effective to identify for OS-level vulnerabilities and misconfigurations, infrastructure scanning solutions are often not designed to be "application-aware." In other words, they may not understand the structure of a Java web application and be able to reach into the WAR of a deployed application on the file system to inspect it for the presence of log4j.
Monitoring by Source Code Management (SCM) Tools
Some SCM platforms offer monitoring of software projects they host and can send alerts when known-vulnerable components are found. Dependabot from GitHub is an example. They can help and, in some cases, make your development teams aware of a vulnerable version of log4j being referenced as a direct dependency. They fall short in that they don't actually build the project and wouldn't have visibility into transitive dependencies for Maven-based Java projects
Specialized Utilities
There are a large number of specialized utilities and purpose-built tools to detect Log4Shell. They may help identify the issue in certain situations but typically are not well-suited for large-scale enterprise use. The following links provide a list of Log4Shell detection tools. Veracode has not verified the effectiveness or safety of these tools.
Another approach that differs from scanning is to review your software inventory. The following site lists many common applications that are known to be vulnerable.
Open Source Is Here to Stay
Just in the last few weeks, two major incidents have shaken the open source community. The poisoning of the ua-parser-js library by crypto-mining, password-stealing malware and the critical, zero-day RCE vulnerability in the log4j-core library. Both libraries have one thing in common: They are trusted and widely used by developer communities, including developers at major tech companies such as Facebook, Apple, Amazon, and Slack.
Let's make no mistake, open source libraries will continue to be used across all industries. While using open source libraries is now an accepted practice in software development, their adoption represents a big challenge from a security point of view. Last week, it was a zero-day vulnerability in a Java library, but, tomorrow, it could be a library in JavaScript, Python, .NET, or ather programming language.
Using outdated and vulnerable open source libraries is a common problem, especially in the Java ecosystem. In our most recent State of Software Security (SOSS) Open Source report, Java ranked third after Ruby and JavaScript in the list of languages where developers don’t keep up with the safest versions of libraries used in their applications. The report also describes how nearly 65 percent of open-source dependencies in Java are never updated after first use.
In terms of vulnerability detection, SCA tools appear to be the most effective choice when a new vulnerability in an open source library hits the news. SCA tools are geared toward accurately identifying and maintaining an inventory of open source components in application portfolios and provide the most context for understanding the vulnerabilities that apply to specific versions.
Related Posts
